fix(engine): count fnmatch label-pattern wildcard groups per raw star, not by path-glob rules by shin-core · Pull Request #10112 · JSONbored/loopover

shin-core · 2026-07-31T07:36:00Z

What & why

labelPatternToRegExp (packages/loopover-engine/src/scoring/label-match.ts) guards against catastrophic backtracking by counting wildcard groups before compiling a label pattern to a RegExp — reusing change-guardrail.ts's hasUnsafeWildcardCount. But that predicate is the path-glob counter, which deliberately treats a ** pair as one group because the path compiler collapses ** into a single .*.

The fnmatch compiler here has no ** concept — it emits one .* per *. So the count and the compiled regex disagreed for any ** pattern:

pattern	path-glob count	actual `.*` groups compiled	old result
`a*b`	2	3	accepted
`/`	2	4	accepted
`abc`	2	4	accepted

The cap's own benchmark puts 3 groups at "over 2 seconds at ~4,000 chars" and 4 at "35 seconds at 1,614 chars", so these accepted patterns are exactly the ones that risk a catastrophic-backtracking RegExp.test() on an adversarial near-miss label. labelMatchesPattern's left-hand input is caller-supplied (ScorePreviewInput.labels) and the right-hand patterns are registry labelMultipliers keys the module itself documents as untrusted.

The fix

Count the groups the fnmatch compiler actually emits — one per raw *, with no ** pairing (? compiles to a single . and […] classes are not counted, neither can backtrack ambiguously) — and compare against MAX_GLOB_WILDCARD_GROUPS, now exported from change-guardrail.ts so the two surfaces share one empirically-safe threshold rather than redeclaring it (the exact drift the existing hasUnsafeWildcardCount export comment warns about).

An over-complex pattern degrades to the existing LABEL_PATTERN_NEVER_MATCHES and is still cached, exactly as today — the fail-safe direction here is "no multiplier applies".

Unchanged: hasUnsafeWildcardCount, countWildcardGroups, globToRegExp, matchesAny and every path-glob consumer keep their **-is-one-group semantics byte-identically (correct for the path compiler — rejecting public/**/*.json there would break the content lane). Every ≤2-group label pattern (type:*, kind/*, priority:?, a*b*c, [bc]ug), the [seq]/[!seq]/invalid-range handling, and the LRU cache behaviour are all preserved.

Tests

Engine (packages/loopover-engine/test/label-match.test.ts, new — node:test per the content-lane-flag.test.ts convention): *a**b and **/** are rejected (never match); the ≤2-group and non-* cases still match; a rejected pattern is still cached (repeated read served from the cache).
Root (test/unit/scoring.test.ts): the same rejection + preserved cases through labelMatchesPattern/labelMultiplierFor. One existing assertion is updated — public/**/*.json (3 compiled groups) is now correctly rejected as a label pattern (it was the path-glob-count's false accept); the comment now states the fnmatch counting rule.
All new assertions fail on main and pass with the fix.

Validation

Diff coverage on both packages/loopover-engine/src/scoring/label-match.ts and .../signals/change-guardrail.ts is 100% line and branch (engine lines credited via the root-vitest upload; the added test is also in packages/loopover-engine/test/** for the dual-upload union).
npm run typecheck clean for these files; npm run engine-parity:drift-check passes; the engine's own node --test suite is green; npm run dead-exports:check clean.
git diff --check clean; no schema/migration/generated-artifact change.

Closes #9994

…, not by path-glob rules labelPatternToRegExp reused change-guardrail's path-glob wildcard-group counter to guard against catastrophic backtracking, but that counter treats a ** pair as ONE group (the path compiler collapses ** into a single .*). The fnmatch compiler here has no ** concept and emits one .* per *, so the count and the compiled regex disagreed for any ** pattern: *a**b counted 2 but compiled 3 .* groups and was wrongly accepted, admitting a pattern this compiler builds into a catastrophic- backtracking RegExp on an adversarial near-miss label. Count one group per raw * (no ** pairing; ? and [..] are not counted) and compare against the shared MAX_GLOB_WILDCARD_GROUPS, now exported from change-guardrail rather than redeclared. An over-complex registry key degrades to the existing LABEL_PATTERN_NEVER_MATCHES and is still cached. The path-glob counter and every path consumer keep their **-is-one-group semantics unchanged. Closes JSONbored#9994

loopover-orb · 2026-07-31T07:36:24Z

Caution

🛑 LoopOver review result - reject/close recommended

_{Review updated: 2026-07-31 08:09:22 UTC}

5 files · 1 AI reviewer · 1 blocker · CI green · clean

🛑 Suggested Action - Reject/Close

Review summary
This PR replaces the reused path-glob wildcard counter with an fnmatch-specific one that counts each raw `*` (matching the fact that the fnmatch compiler emits one `.*` per `*`, with no `**` special-casing), and shares `MAX_GLOB_WILDCARD_GROUPS` from change-guardrail.ts instead of redeclaring the threshold. The logic is verified correct by tracing the compiler's per-character loop in `labelPatternToRegExp` (each `*` unconditionally emits `.*`), and the new/updated tests (label-match.test.ts, scoring.test.ts) exercise the real reachable path with concrete `**`-containing patterns that were previously undercounted and accepted. The diff also silently adds an unrelated binary artifact (`apps/loopover-ui/public/downloads/loopover-extension.zip`) with zero connection to the stated fnmatch-counting fix.

Blockers

An unrelated binary file, `apps/loopover-ui/public/downloads/loopover-extension.zip`, is added in this diff with no source, no documentation, and no stated connection to the fnmatch-wildcard-counting fix — this is scope creep that must be pulled into its own PR or explained before merge.

Nits — 4 non-blocking

`fnmatchWildcardGroups` (label-match.ts:48) hardcodes the comparison threshold via the shared `MAX_GLOB_WILDCARD_GROUPS`, which is good, but the function itself has no named constant for the `*` character check — minor, purely stylistic.
The new `label-match.test.ts` imports from `../dist/scoring/label-match.js` rather than the source path used elsewhere in the test suite (e.g. `test/unit/scoring.test.ts` imports from `../../src/scoring/preview`) — worth confirming this dual test/dist split is an intentional existing convention and not accidental drift.
Split the `loopover-extension.zip` addition into a separate, explicitly-described PR so reviewers can evaluate it on its own merits.
Consider adding one more test case for a pattern with exactly `MAX_GLOB_WILDCARD_GROUPS + 1` raw stars with no `**` (e.g. `a*b*c*d`) to make explicit that the threshold is purely about raw-star count, independent of any `**` adjacency, since all current over-cap tests happen to include a `**` pair.

Why this is blocked

An unrelated binary file, `apps/loopover-ui/public/downloads/loopover-extension.zip`, is added in this diff with no source, no documentation, and no stated connection to the fnmatch-wildcard-counting fix — this is scope creep that must be pulled into its own PR or explained before merge.

📋 Copy for AI agents — paste into your coding agent

Fix the following blocker(s) from this PR review:

1. An unrelated binary file, \`apps/loopover-ui/public/downloads/loopover-extension.zip\`, is added in this diff with no source, no documentation, and no stated connection to the fnmatch-wildcard-counting fix — this is scope creep that must be pulled into its own PR or explained before merge.

Decision drivers

❌ Code review — 1 blocker (1 reviewer)
❌ Gate result — Blocking (Repo-configured hard blocker found.)

Context & advisory signals — never blocks the verdict

Signal	Result	Evidence
Linked issue	✅ Linked	#9994
Related work	✅ No active overlap found	No same-issue or scoped active PR overlap found.
Change scope	✅ 20/20	Low review scope from cached public metadata (1 linked issue).
Validation posture	✅ 25/25	PR body includes validation/test evidence.
Contributor workload	✅ 10/10	Author activity: 65 registered-repo PR(s), 50 merged, 0 issue(s).
Contributor context	✅ Confirmed Gittensor contributor	shin-core; Gittensor profile; 65 PR(s), 0 issue(s).
Improvement	✅ Minor	risk: clean · value: minor · LLM: moderate

Linked issue satisfaction

Addressed
The diff replaces the reused path-glob hasUnsafeWildcardCount predicate with a new fnmatch-specific counter that counts one group per raw '*' (no ** pairing, '?' and classes uncounted), compares against the shared exported MAX_GLOB_WILDCARD_GROUPS from change-guardrail.ts, preserves the LABEL_PATTERN_NEVER_MATCHES/caching fallback, leaves change-guardrail's path-glob counting semantics untouched,

Review context

Author: shin-core
Role context: outside_contributor
Public audience mode: oss maintainer
Lane context: Repository is configured for direct PR review.
Public profile languages: not available
Official Gittensor activity: 65 PR(s), 0 issue(s).
PR-specific overlap: none found.

Contributor next steps

Start here: Triage stale or unlinked PRs.

Signal definitions

Related work = same linked issue, overlapping active PRs, or title/path similarity.
Change scope = cached public metadata such as size labels, draft state, and review-burden hints.
Validation posture = whether the PR provides enough public validation/test evidence for maintainer review.
Contributor workload = public contributor activity and cleanup pressure, not a repo-wide quality failure.
Contributor context = public GitHub/Gittensor identity context; non-Gittensor status is not a blocker.

🧪 Chat with LoopOver

Ask LoopOver a question about this PR directly in a comment — grounded only in the same cached, public-safe facts shown above, never a new claim.

@loopover ask <question> answers contribution-quality Q&A with source citations and freshness.
@loopover chat <question> answers in natural prose from cached decision-pack facts via local inference (maintainer/collaborator; read-only).
A plain-language @loopover mention with a real question is routed to the closest matching read-only command automatically — no exact syntax required.

Full command reference: https://loopover.ai/docs/loopover-commands

🧪 Experimental — new and may change.

Visual preview

Route	Viewport	Before (production)	After (this PR's preview)	Diff
`/`	desktop	_{before /}	_{after /}	—
`/`	mobile	_{before / (mobile)}	_{after / (mobile)}	—

Click any thumbnail to open the full-size screenshot. Before = production · After = this PR's preview deploy.

Scroll preview

Route	Before (production)	After (this PR's preview)
`/`	_{before / (scroll)}	_{after / (scroll)}

A short scroll-through clip (desktop) — click either thumbnail to open the full animation. Evidence for scroll-linked behavior a single screenshot can't show.

_{🟩 Safe / merged · 🟦 Advisory · 🟨 Held for review · 🟥 Blocked / closed}

💰 Earn for open-source contributions like this. Gittensor lets GitHub contributors earn for the work they already do — register to start earning →.

Checked by LoopOver, a quiet PR intelligence layer for OSS maintainers.

Re-run LoopOver review

superagent-security · 2026-07-31T07:37:04Z

Superagent didn't find any vulnerabilities or security issues in this PR.

codecov · 2026-07-31T08:07:06Z

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 91.98%. Comparing base (9f673b8) to head (ee48b7e).
⚠️ Report is 7 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main   #10112      +/-   ##
==========================================
+ Coverage   91.95%   91.98%   +0.02%     
==========================================
  Files         931      931              
  Lines      113921   113939      +18     
  Branches    27504    27511       +7     
==========================================
+ Hits       104757   104806      +49     
+ Misses       7863     7828      -35     
- Partials     1301     1305       +4

Flag	Coverage Δ
backend	`95.66% <100.00%> (-0.01%)`	⬇️
engine	`72.93% <100.00%> (+0.20%)`	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

Files with missing lines	Coverage Δ
...ackages/loopover-engine/src/scoring/label-match.ts	`92.81% <100.00%> (+23.73%)`	⬆️
...es/loopover-engine/src/signals/change-guardrail.ts	`97.40% <100.00%> (+0.03%)`	⬆️

... and 1 file with indirect coverage changes

loopover-orb · 2026-07-31T08:09:30Z

LoopOver is closing this pull request on the maintainer's behalf (AI review flagged a likely critical defect: An unrelated binary file, `apps/loopover-ui/public/downloads/loopover-extension.zip`, is added in this diff with no source, no documentation, and no stated connection to the fnmatch-wildcard-counting fix — this is scope creep that must be pulled into its own PR or explained before merge.). This is an automated maintenance action — to pursue this change, please open a new pull request with the issues resolved. Closed PRs may be analyzed later to improve review accuracy, but they are not automatically reopened or re-reviewed.

shin-core requested a review from JSONbored as a code owner July 31, 2026 07:36

github-actions Bot deployed to preview/pr-10112 July 31, 2026 07:44 View deployment

loopover-orb Bot added the gittensor:bug Gittensor-scored bug fix — scores a 0.05x multiplier. label Jul 31, 2026

loopover-orb Bot assigned shin-core Jul 31, 2026

loopover-orb Bot closed this Jul 31, 2026

Navigation Menu

Uh oh!

fix(engine): count fnmatch label-pattern wildcard groups per raw star, not by path-glob rules - #10112

fix(engine): count fnmatch label-pattern wildcard groups per raw star, not by path-glob rules#10112
shin-core wants to merge 1 commit into
JSONbored:mainfrom
shin-core:fix/label-match-fnmatch-wildcard-count-9994

shin-core commented Jul 31, 2026

Uh oh!

loopover-orb Bot commented Jul 31, 2026 •

edited

Loading

🛑 LoopOver review result - reject/close recommended

Uh oh!

superagent-security Bot commented Jul 31, 2026

Uh oh!

codecov Bot commented Jul 31, 2026

Uh oh!

loopover-orb Bot commented Jul 31, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Uh oh!

Conversation

shin-core commented Jul 31, 2026

What & why

The fix

Tests

Validation

Uh oh!

loopover-orb Bot commented Jul 31, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

🛑 LoopOver review result - reject/close recommended

Uh oh!

superagent-security Bot commented Jul 31, 2026

Uh oh!

codecov Bot commented Jul 31, 2026

Codecov Report

Uh oh!

loopover-orb Bot commented Jul 31, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

loopover-orb Bot commented Jul 31, 2026 •

edited

Loading